Skip to content

fix(msc): correct SD SPI fops symbol name in usbd_storage_sd_spi.c#1242

Merged
nerdCopter merged 8 commits into
emuflight:masterfrom
nerdCopter:fix/msc-sd-spi-fops
Jun 3, 2026
Merged

fix(msc): correct SD SPI fops symbol name in usbd_storage_sd_spi.c#1242
nerdCopter merged 8 commits into
emuflight:masterfrom
nerdCopter:fix/msc-sd-spi-fops

Conversation

@nerdCopter
Copy link
Copy Markdown
Member

@nerdCopter nerdCopter commented Jun 3, 2026

AI Generated pull-request

Summary

src/main/msc/usbd_storage_sd_spi.c defined USBD_MSC_MICRO_SDIO_fops instead of USBD_MSC_MICRO_SD_SPI_fops. src/main/drivers/usb_msc_h7xx.c references USBD_MSC_MICRO_SD_SPI_fops on its #elif defined(USE_SDCARD_SPI) branch, so any H7 target with USE_SDCARD_SPI only (no USE_SDCARD_SDIO) failed to compile:

usb_msc_h7xx.c:93: error: 'USBD_MSC_MICRO_SD_SPI_fops' undeclared

The wrong name also caused a latent duplicate-symbol when both USE_SDCARD_SDIO and USE_SDCARD_SPI were defined simultaneously, since both usbd_storage_sd_spi.c and usbd_storage_sdio.c would define the same USBD_MSC_MICRO_SDIO_fops symbol.

Changes:

  • src/main/msc/usbd_storage_sd_spi.c: rename USBD_MSC_MICRO_SDIO_fopsUSBD_MSC_MICRO_SD_SPI_fops (both HAL and legacy variants)
  • src/main/msc/usbd_storage.h: rename extern declarations to match

src/main/msc/usbd_storage_sdio.c is unchanged — it continues to define USBD_MSC_MICRO_SDIO_fops correctly.

BF 4.5-m parity: usbd_storage_sd_spi.c in BF uses USBD_MSC_MICRO_SD_SPI_fops.

Closes #1241.

Test plan

  • Build passes: KAKUTEH7 (USE_SDCARD_SPI), MATEKH743 (USE_SDCARD_SDIO)
  • Hardware verified: n/a (symbol rename only)

Summary by CodeRabbit

  • Refactor
    • Reorganized USB mass storage configuration with improved separation of storage backends for SDIO and SPI SD cards, flash filesystem support, and HAL driver variants.

usbd_storage_sd_spi.c defined USBD_MSC_MICRO_SDIO_fops instead of
USBD_MSC_MICRO_SD_SPI_fops. usb_msc_h7xx.c (and f7xx.c) reference the
SPI name on the #elif USE_SDCARD_SPI branch, so any target with only
USE_SDCARD_SPI (no USE_SDCARD_SDIO) failed with 'undeclared identifier'.
Also caused a latent duplicate-symbol when both SDIO and SPI were enabled.

Fix: rename to USBD_MSC_MICRO_SD_SPI_fops in both usbd_storage_sd_spi.c
and usbd_storage.h. usbd_storage_sdio.c retains USBD_MSC_MICRO_SDIO_fops
unchanged. Closes emuflight#1241.
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Jun 3, 2026

Review Change Stack

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8361d58b-d99c-45fc-9d87-9b002ee7bb87

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

This PR corrects the USB mass-storage SPI backend symbol name from USBD_MSC_MICRO_SDIO_fops to USBD_MSC_MICRO_SD_SPI_fops across extern declarations and definitions, with reorganized preprocessor guards for HAL and non-HAL configurations.

Changes

SD Card SPI fops symbol correction

Layer / File(s) Summary
Header extern declarations with corrected guards
src/main/msc/usbd_storage.h
Under USE_HAL_DRIVER, USBD_StorageTypeDef externs are conditionally declared for SDIO, SPI, and FLASHFS backends. Under non-HAL, USBD_STORAGE_cb_TypeDef externs split SD support into separate USE_SDCARD_SDIO and USE_SDCARD_SPI guards.
Implementation symbol definitions
src/main/msc/usbd_storage_sd_spi.c
Global USBD_MSC_MICRO_SD_SPI_fops function-table symbols are defined under both USE_HAL_DRIVER (StorageTypeDef) and non-HAL (STORAGE_cb_TypeDef) code paths, correcting the SDIO variant symbol name.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: correcting the SD SPI fops symbol name in usbd_storage_sd_spi.c from USBD_MSC_MICRO_SDIO_fops to USBD_MSC_MICRO_SD_SPI_fops.
Description check ✅ Passed The pull request description is well-structured with clear summary, problem statement, changes, and test plan. However, it does not fully follow the template which requires removal of the boilerplate instructions.
Linked Issues check ✅ Passed The pull request successfully addresses all coding requirements from issue #1241: renaming the fops symbol to USBD_MSC_MICRO_SD_SPI_fops, updating extern declarations with separate guards, and resolving the compile error and duplicate-symbol issues.
Out of Scope Changes check ✅ Passed All changes are directly scoped to issue #1241: symbol rename in usbd_storage_sd_spi.c and corresponding extern declarations in usbd_storage.h. No unrelated modifications detected.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@nerdCopter nerdCopter marked this pull request as ready for review June 3, 2026 21:46
Previous commit replaced USBD_MSC_MICRO_SDIO_fops in usbd_storage.h,
removing the extern needed by usb_msc_f7xx.c, usb_msc_h7xx.c (SDIO branch),
and usb_msc_f4xx.c. Restore it under a USE_SDCARD_SDIO guard and add
the SPI fops under USE_SDCARD_SPI, matching BF 4.5-m usbd_storage.h
which uses separate guards for each symbol.
Targets that define only USE_SDCARD (no sub-type, e.g. ANYFCF7) broke
when the SDIO fops extern was narrowed to USE_SDCARD_SDIO. Restore the
broad USE_SDCARD guard for USBD_MSC_MICRO_SDIO_fops to preserve F4/F7
backward compat; keep the new USE_SDCARD_SPI guard for the SPI fops
that fixes H7 targets.
usb_msc_h7xx.c used USBD_MSC_MICRO_SD_SPI_fops on the USE_SDCARD_SPI
branch — a symbol that does not exist in EmuFlight. EF uses
USBD_MSC_MICRO_SDIO_fops as the unified SPI SD storage fops name
(defined in usbd_storage_sd_spi.c). Use the existing EF symbol.
Closes emuflight#1241.
@nerdCopter
Copy link
Copy Markdown
Member Author

AI Generated comment

@coderabbitai, new push after prior approach was reverted. The PR is now a single-line fix: usb_msc_h7xx.c USE_SDCARD_SPI branch referenced USBD_MSC_MICRO_SD_SPI_fops which does not exist in EmuFlight. EF's usbd_storage_sd_spi.c defines USBD_MSC_MICRO_SDIO_fops as the SPI SD MSC fops name; the fix aligns the H7 caller to use that existing symbol. No renames, no architectural changes. Please review for correctness and regressions.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Jun 3, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Get the current diff of PR `#1242`
gh pr diff 1242 --repo emuflight/EmuFlight

echo "---FILES CHANGED---"
gh pr view 1242 --repo emuflight/EmuFlight --json files --jq '.files[].path'

echo "---PR STATUS---"
gh pr view 1242 --repo emuflight/EmuFlight --json title,state,headRefName,baseRefName,body

Length of output: 2784


🏁 Script executed:

#!/bin/bash
echo "=== All references to USBD_MSC_MICRO_SD_SPI_fops ==="
rg -n "USBD_MSC_MICRO_SD_SPI_fops"

echo ""
echo "=== All references to USBD_MSC_MICRO_SDIO_fops ==="
rg -n "USBD_MSC_MICRO_SDIO_fops"

echo ""
echo "=== usb_msc_*.c files ==="
fd -e c "usb_msc_" --exec cat {}

echo ""
echo "=== usbd_storage.h ==="
fd -e h "usbd_storage" --exec cat {}

Length of output: 15318



@nerdCopter: The revised single-line fix looks correct. Here's my analysis:

Fix correctness ✅

rg confirms there are now zero references to USBD_MSC_MICRO_SD_SPI_fops anywhere in the codebase — the compile error is fully resolved, and no stale callers remain.

Consistency with F4/F7 ✅

Both usb_msc_f4xx.c and usb_msc_f7xx.c already use a single USE_SDCARD guard pointing to USBD_MSC_MICRO_SDIO_fops for all SD card types. The H7 fix brings the same behaviour, making all three MCU families consistent.

Duplicate-symbol risk ✅ (no regression)

usbd_storage_sd_spi.c and usbd_storage_sdio.c each define USBD_MSC_MICRO_SDIO_fops, but only one is compiled per target since USE_SDCARD_SDIO and USE_SDCARD_SPI are mutually exclusive at the board level. This was true before the PR and remains unchanged.

usbd_storage.h ✅ (no change needed)

The existing #ifdef USE_SDCARD guard covering extern USBD_MSC_MICRO_SDIO_fops is sufficient for both SPI and SDIO callers — no header edits are required.

Minor observation (non-blocking)

After the fix, both branches of the #ifdef in usb_msc_h7xx.c are identical:

`#ifdef` USE_SDCARD_SDIO
    USBD_MSC_RegisterStorage(&USBD_Device, &USBD_MSC_MICRO_SDIO_fops);
`#elif` defined(USE_SDCARD_SPI)
    USBD_MSC_RegisterStorage(&USBD_Device, &USBD_MSC_MICRO_SDIO_fops);

These could be collapsed to #if defined(USE_SDCARD_SDIO) || defined(USE_SDCARD_SPI), matching the simpler pattern in the F4/F7 files. Not a blocker, but worth a follow-up cleanup.

Overall the approach is sound — minimal, targeted, and no regressions. ✅


✏️ Learnings added
Learnt from: nerdCopter
URL: https://github.com/emuflight/EmuFlight/pull/1242

Timestamp: 2026-06-03T22:50:55.387Z
Learning: In EmuFlight (emuflight/EmuFlight), PR `#1242` fixed a compile error on H7 targets with USE_SDCARD_SPI. The fix was a single-line change in src/main/drivers/usb_msc_h7xx.c: the USE_SDCARD_SPI branch was changed to reference USBD_MSC_MICRO_SDIO_fops (the symbol that usbd_storage_sd_spi.c actually defines) instead of the non-existent USBD_MSC_MICRO_SD_SPI_fops. An earlier approach that renamed the symbol in usbd_storage_sd_spi.c and usbd_storage.h was reverted in favour of this minimal caller-side fix. Both usb_msc_f4xx.c and usb_msc_f7xx.c already used USBD_MSC_MICRO_SDIO_fops under a USE_SDCARD guard for all SD card types; the H7 fix is now consistent with them. usbd_storage.h requires no changes — the existing USE_SDCARD guard covering the USBD_MSC_MICRO_SDIO_fops extern is sufficient for both SDIO and SPI implementations.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.


🧠 Learnings used
Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 0
File: :0-0
Timestamp: 2026-04-04T21:55:50.478Z
Learning: In the EmuFlight project (GitHub: emuflight/EmuFlight), issue `#1106` involves CLI AutoComplete stalls on HELIOSPRING/STRIXF10/MODE2FLUX boards caused by USB VCP write starvation under EXTI preemption. The proposed fix (disabling EXTI via `EXTIEnable()` in `cliEnter()` and re-enabling in `cliExit()`/`cliRebootEx()`) was initially rejected due to apparent "permanent gyro corruption requiring reflash." However, this regression was later identified as a pre-existing configurator CLI/MSP reconnect bug present in the EmuFlight configurator NWjs master branch (not just an Electron/Forge migration bug). The configurator fails to properly re-establish MSP polling after CLI exits; a reflash incidentally forces USB re-enumeration which triggers a clean reconnect, masking the real cause. The EXTI fix itself is logically sound and should be re-evaluated using firmware-independent gyro verification (raw MSP tool) rather than the buggy configurator.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 0
File: :0-0
Timestamp: 2026-05-28T19:13:36.183Z
Learning: For EmuFlight PR `#1194` STM32H7 support, NAND erase blocking interactions with USB MSC are intentionally tracked under the separate `h7-flash-mashup` scope and should not be treated as blockers for the core STM32H7 port.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 0
File: :0-0
Timestamp: 2026-05-29T15:36:21.638Z
Learning: In `src/main/drivers/flash_w25n.c` (EmuFlight PR `#1204`), all code patterns that appear as potential issues are faithful backports of BF 4.5-maintenance. Specifically: (1) the BBLUT SPI callback `<< 16` shift (line ~1022) is a pre-existing BF bug tracked as EF `#1212` / BF `#15271`; (2) the QuadSPI BBLUT path reading from `in` instead of `bblutBuffer` (line ~1079) is the same BF bug; (3) the outer `#ifdef USE_QUADSPI` wrapping `w25n_programDataLoad`/`w25n_randomProgramDataLoad` is intentional since they are only called from the QuadSPI pageProgramContinue path; (4) `bufferDirty` and `isProgramming` being non-static matches BF 4.5-maintenance. Do not flag any of these as divergences from BF upstream.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 1204
File: src/main/drivers/flash_m25p16.c:237-238
Timestamp: 2026-05-28T20:30:26.246Z
Learning: In emuflight/EmuFlight, the flash driver backport from BF 4.5-maintenance (PR `#1204`) intentionally preserves verbatim upstream code including the duplicate consecutive assignment `fdevice->couldBeBusy = true;` in `src/main/drivers/flash_m25p16.c` (around lines 237–238). This is by design to maintain exact upstream parity with Betaflight 4.5-maintenance `flash_m25p16.c` lines 231–232, and should not be flagged as a bug in future reviews.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 0
File: :0-0
Timestamp: 2026-05-30T17:48:26.388Z
Learning: In EmuFlight (repository: emuflight/EmuFlight), the following bugs were present in the BF 4.5-maintenance flash driver backport but were intentionally fixed in EmuFlight in commit `9f424ae95d` (PR `#1225`), diverging from upstream BF. Do NOT flag these as "BF parity" items in future reviews — they are fixed in EmuFlight:
1. `m25p16_waitForReady` in `src/main/drivers/flash_m25p16.c`: now has a 500 ms timeout; the previous infinite `while (!m25p16_isReady(fdevice));` spin is gone.
2. `m25p16Qspi_vTable` in `src/main/drivers/flash_m25p16.c`: now includes `.configure`; the previous NULL pointer omission is fixed.
3. `w25m_pageProgramBegin` in `src/main/drivers/flash_w25m.c`: now correctly passes `currentWriteAddress` (die-relative) instead of the raw `address` parameter.
4. BBLUT SPI callback in `src/main/drivers/flash_w25n.c`: shift changed from `<< 16` to `<< 8` for both `pba` and `lba` (was tracked as EF issue `#1212` / upstream BF#15271).
5. `w25q128fv_pageProgramContinue` in `src/main/drivers/flash_w25q128fv.c`: now accumulates `bytesWritten`, sets `callbackArg`, and invokes callback in `pageProgramFinish`; the prior uninitialized return is fixed.
The only remaining intentional BF-parity divergences (still present in EmuFlight) are: duplicate `couldBeBusy = true` at lines 231–232 in `flash_m25p16.c`, and the `flashPartitionSet` off-by-one guard (`== FLASH_MAX_PARTITIONS - 1`) in `flash.c`.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 0
File: :0-0
Timestamp: 2026-05-30T17:59:21.173Z
Learning: In EmuFlight (repository: emuflight/EmuFlight), the `flashPartitionSet` off-by-one guard (`flashPartitions == FLASH_MAX_PARTITIONS - 1` instead of `>=`) in `src/main/drivers/flash.c` is a known BF 4.5-maintenance parity item intentionally retained for PR `#1225`. It is tracked in EmuFlight as issue `#1226` (referencing upstream BF#15279) for post-merge resolution. Do NOT flag it as a new bug during review of this PR — it has zero runtime impact with current single-partition usage and is acknowledged by maintainers.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 0
File: :0-0
Timestamp: 2026-04-23T20:41:53.090Z
Learning: In EmuFlight PR `#1118` (Stage L.2), the correct merge order is: companion targets-only PR `#1119` (macro renames: *_SPI_INSTANCE → *_SPI_BUS across target.h files) must merge first, then `#1118` (call-site migration + forwarder removal in source files). CI failures for undeclared *_SPI_BUS macros in `#1118` standalone are a known merge-order artefact, not code bugs.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 1204
File: src/main/drivers/flash.c:431-436
Timestamp: 2026-05-28T20:31:08.837Z
Learning: In emuflight/EmuFlight PR `#1204`, the `flashPartitionSet` function in `src/main/drivers/flash.c` uses the guard `flashPartitions == FLASH_MAX_PARTITIONS - 1` (off-by-one relative to what CodeRabbit flagged). The maintainer accepted this as-is citing BF 4.5-maintenance parity. Note: BF master `flash.c` line 585 reportedly uses `flashPartitions == FLASH_MAX_PARTITIONS` (without the `-1`), so the exact upstream source should be verified if strict parity is required.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 0
File: :0-0
Timestamp: 2026-04-22T20:55:55.130Z
Learning: In the EmuFlight refactor series (emuflight/EmuFlight, PRs `#1111`, `#1114`, `#1116`, etc.), new-code findings are actionable only if Betaflight 4.5-maintenance does the equivalent. The distinguishing criterion for I2C vs SPI return-value checking: BF 4.5-m's `i2cBusSetInstance` callers do NOT check the return value (so adding a return-value guard in EmuFlight would diverge from BF), whereas BF 4.5-m's `spiSetBusInstance` callers DO check the return (making SPI-side return-check guards in-scope). Adding EF-only documentation or guards to BF-parity functions creates maintenance drift and is out of scope for this series.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 0
File: :0-0
Timestamp: 2026-04-24T19:48:08.632Z
Learning: In EmuFlight bus_spi_impl.h (Stage M, PR `#1121`), the header intentionally has no self-contained includes and relies on includer-ordering, because BF 4.5-maintenance bus_spi_impl.h lines 87-92 are identical in structure (same function stubs, no includes, same reliance). This is a pre-existing upstream pattern and should not be flagged as a deficiency in EmuFlight refactor PRs. The issue was filed as EmuFlight `#1122` for upstream tracking.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 1225
File: src/main/target/common_fc_post.h:209-223
Timestamp: 2026-05-30T19:05:58.951Z
Learning: In `src/main/target/common_fc_post.h` (EmuFlight), the flash macro normalization block (USE_FLASH_CHIP, USE_FLASH_TOOLS, USE_FLASHFS auto-enable/rollback) is placed *after* the `USE_USB_MSC` pruning check at line ~153. This ordering is intentional BF 4.5-maintenance parity (identical to upstream Betaflight 4.5-maintenance source). Do not flag the interaction between the flash normalization block and the earlier USB_MSC pruning as a bug.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 0
File: :0-0
Timestamp: 2026-05-03T19:12:36.441Z
Learning: In `src/main/drivers/accgyro/accgyro_mpu.c` (`detectSPISensorsAndUpdateDetectionResult`), the established convention for standard SPI IMU drivers (MPU6000, MPU6500, MPU9250, ICM20689) is to call `spiSetBusInstance(&gyro->dev, SPI_DEV_TO_CFG(<IMU>_SPI_BUS))` directly with no `#ifdef <IMU>_SPI_BUS` guard and no `#else `#error``. The `#ifdef ICM20649_SPI_BUS` / `#ifdef ICM42688P_SPI_BUS` guards on ICM blocks are pre-existing and predate the guard-consistency fix PR `#1145`. IMUF9001's `#error` is an intentional architectural outlier (proprietary dual-MCU F405+F301 coprocessor), not the reference pattern for standard IMU detection. Adding `#else `#error`` only to ICM blocks without updating MPU blocks would increase inconsistency; a uniform cleanup is a separate future effort.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 1225
File: src/main/drivers/flash_m25p16.c:627-641
Timestamp: 2026-05-30T18:48:28.142Z
Learning: In emuflight/EmuFlight PR `#1225` (flash driver backport), the missing `.configure = m25p16_configure` entry in `m25p16Qspi_vTable` in `src/main/drivers/flash_m25p16.c` was fixed in commit 9f424ae95d. The QSPI vtable now matches the SPI vtable with the configure pointer populated to prevent a NULL dereference when flashConfigure() is called on QSPI devices.

Learnt from: nerdCopter
Repo: emuflight/EmuFlight PR: 0
File: :0-0
Timestamp: 2026-05-30T16:48:32.440Z
Learning: In EmuFlight (repository: emuflight/EmuFlight), the flash driver stack in `src/main/drivers/flash_m25p16.c`, `src/main/drivers/flash_w25m.c`, `src/main/drivers/flash_w25n.c`, `src/main/drivers/flash_w25q128fv.c`, and `src/main/drivers/flash.c` was backported from Betaflight 4.5-maintenance (PR `#1225`). The following patterns are intentional BF 4.5-m parity items and should NOT be flagged as bugs:
1. `m25p16_waitForReady` spins with `while (!m25p16_isReady(fdevice));` — no timeout, identical to BF.
2. Duplicate `couldBeBusy = true` assignments at lines 231–232 in `flash_m25p16.c` — identical to BF, both lines intentional.
3. `m25p16Qspi_vTable` (QSPI vtable) is missing `.configure` — identical omission in BF.
4. `w25m_pageProgramBegin` passes the full `address` parameter rather than `currentWriteAddress` — identical to BF at line 207 of `flash_w25m.c`.
5. BBLUT `<< 16` shift overflow in `flash_w25n.c` lines 1015–1016 — pre-existing BF bug filed as BF#15271, tracked in EF as issue `#1212`.
6. `w25q128fv_pageProgramContinue` returns `fdevice->callbackArg` — identical to BF at line 430 of `flash_w25q128fv.c`.
7. `flashPartitionSet` off-by-one guard (`== FLASH_MAX_PARTITIONS - 1`) — identical to BF at line 585 of `flash.c`.

Both USE_SDCARD_SDIO and USE_SDCARD_SPI branches called the same
USBD_MSC_RegisterStorage line. Collapse to a single || guard,
consistent with the simpler pattern in usb_msc_f4xx.c and usb_msc_f7xx.c.
@nerdCopter nerdCopter merged commit afc8c85 into emuflight:master Jun 3, 2026
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix(msc): usbd_storage_sd_spi.c defines wrong fops symbol name

1 participant